Subject: DLSw Scalability enhancement proposal

From: [email-masked] (Ravi C. Periasamy)
Date: Tue, 27 Jun 1995 12:12:26 -0400

Hi,

Here's the proposal for the DLSw scalability enhancements I presented
at the AIW at San Jose. I am copying aiw-dlsw, since there were some
problems with the new mailing lists.

If any part of the proposal is not clear, email me.

Ravi Periasamy,
[email-masked]

------------- DLSw scalability enhancement proposal ----------------

DLSw scalability extensions proposal
----------------------------------

The goals of this proposal is to extend DLSw functionality to
achieve:
         - Improved scalability
         - More flexible peer types and connections
         - Any-to-Any connectivity for large networks
         - Handling multiple paths more efficiently

PASSIVE PEERS:
--------------
In the current DLSw standard, WAN connections are actively brought
up for all the peers configured by the user. But with the
PASSIVE PEER extension, if a peer is configured as "Passive"
by the user, the peer connection is not actively brought up by
the DLSw entity. It waits for the remote peer to actively establish
the connection. This feature is used to configure peers, for
security purposes, but at the same time save one of the two peers
from trying to bring up the session.

This could be used in hierarchical networks, where the host side
router has all the access routers configured but does not initiate
the WAN connection.

Note that at least one of the two sides must have the peer
connection configured as NOT PASSIVE.

PEER-ON-DEMAND:
----------------
Peer-on-demand peer connections are  established dynamically by
DLSw for reachability to specific resources.  A peer-on-demand peer
could be either configured as such by the user statically or
learned dynamically by the router using border peers (detailed later).

When configured statically, the user must also configure static
cache entries to be used by DLSw. The peer connection is
established when link to the target resource is required. Once
the Circuit established through the POD peer is closed, the peer
connection is closed (after a small period of time). The peer that
initiated the POD session should be responsible for taking down
the session.

One general rule to be used is that the Source peer should not
forward any explorer traffic unless the target station is known
to be on the POD peer.

The POD peer may also be dynamically learned by the source router
through border peers. Refer to the section on  Border Peers for
more information.

Note: When using border peers to dynamically bring up POD peers,
the target peer must either be configured to accept WAN
connections from any peer (promiscuous) or be configured with the
source peer as a passive peer connection. If the target peer is not
configured/equipped to accept peer connection from the source peer,
all frames from that peer should be dropped and not forwarded to
the LAN.

We have two options to handle POD peers:
     1. Peer Type may be added to the capabilities exchange
     2. The POD peer may list the resources that it can reach
        and set the exclusive flag. This will (if handled at the
        target end) prevent any broadcast flow from the other
        side for resources not reachable.

If option 1 is chosen: Add a "Peer Type" to the capabilities
exchange.

BACKUP PEERS:
--------------
When in Peer A, a peer (peer C) is configured to be a backup of
another peer (peer B), the connection to peer C is brought up
only when connection to Peer B is down. When Peer B comes back
up again, Peer C may be either brought down or may be brought
down after all the Circuits through that peer are brought down
by the end stations.

Here again Peer type will be helpful. Also, if a decision is
taken NOT to take down the session until all the circuits
through the backup peer are taken down, we may need to add a
new message to be sent from Peer A to Peer C, to drop any
broadcast frames and also NOT to bring up any new connections,
when connection to peer B comes up.

Alternately, Peer A may choose to drop all broadcast frames and
new connection requests from Peer C. Even though this may be
easier to implement, The first option allows us to reduce
traffic over the WAN, when the primary peer comes back up.

PEER COSTS:
------------
When multiple paths exist between peers, 'peer costs' could be
used to pick one of the peer connections for new circuits.
This gives users control over which of the several possible
peers are to be used for new circuits.

An option may be given to the user to configure Peer Connection
cost, which overrides the peer cost.

The peer costs are from range 1 to 5, with 1 as the lowest cost
and 5 as the highest cost. Lower cost is considered better!

For example, If peer A is configured a cost of 3, Peer B with a
cost of 4 and Peer C with a cost of 2, Peer A will choose Peer C
over Peer B. This cost information is passed in the capabilities
exchange.

But if the user configures (in Peer A), the path cost of Peer B
to be 1, that overrides the cost received in capabilities
exchange, and is used by Peer A, and hence in our example,
Peer A will choose Peer B over Peer C.

This option enables the user to weight one Peer as favorable to
a set of peers while configuring another to be favorable for a
different set of peers.

Add "Peer Cost" to capabilities exchange.

PEER GROUPS and BORDER PEERS:
------------------------------
Peer groups is a logical grouping of a set of peers. One or more
of the members of the group are designated as the Border Peer,
which acts as the leader of the group. This designation needs to
be done only at the peer that needs to be designated as the
border peer. This information is passed by the border Peer in
capabilities exchange to the other members of the peer group.

When a group member (which is not a border peer) needs to send
a broadcast frame, it sends the frame to the border peer (if one
is available). It also sends the frame to other peers in its
list that do not belong to its own group.

When border peer receives such a relay frame, from its group
member, it sends it  to other members of the group and also to
border peers of other groups. But when a relay frame is received
from the a border peer of another group, the frame is relayed
only to members of the group and NOT to a border peer of another
group.

At the AIW the issue of using IP multicasting was raised.
Peer groups could be used to compliment IP multicasting. Peer
groups grouping is logical and not necessarily physical. So If
IP multicasting is available, the border peer may choose to use
that service to send the frame to multicast capable peers and
send it the 'traditional way' to the other peers in the group.

Border Peers can also be used to relay directed frames
(typically ICR_ex, and Name Recognized frames) to other peers.
When a response is received through the border peer, a Peer on
demand session may be established, if a circuit is to be
established through that peer.

This feature changes the point of broadcast from the access
router to a different point, with better resources.

Add:
   ushort    group_no;    /* group number this peer belongs to.
                             Set to 0 the peer does not
                             belong to any group */
   boolean   border_peer; /* TRUE if this is a border peer
                             for the group */
to the capabilities exchange.

Relay header format:
The frame to be relayed (the complete SSP frame including the
SSP header) is encapsulated using the following structure.

OPTION 1: (As presented at the AIW)
     +------------------------+------------------------+
     | protocol_version_id    | message_type           |
     +------------------------+------------------------+
     | packet_length                                   |
     +------------------------+------------------------+
     | origin_group           | target_group           |
     +------------------------+------------------------+
     | origin_wan_protocol    | target_wan_protocol    |
     +------------------------+------------------------+
     | origin_peer_id                                  |
     +------------------------+------------------------+
     |                                                 |
     +------------------------+------------------------+
     | target_peer_id                                  |
     +------------------------+------------------------+
     |                                                 |
     +------------------------+------------------------+

Note that the origin and target peer_ids are each 4 bytes long.
The IP address of the peers are stored here. This assumes TCP/IP
support for such dynamic Peer on Demand.

OPTION 2: (After incorporating some feedback received at the AIW)

     +------------------------+------------------------+
     | protocol_version_id    | message_type           |
     +------------------------+------------------------+
     | packet_length                                   |
     +------------------------+------------------------+
     | origin_group           | target_group           |
     +------------------------+------------------------+
     | origin_wan_protocol    | target_wan_protocol    |
     +------------------------+------------------------+
     | origin_peer_id                                  |
     +------------------------+------------------------+
     |                                                 |
     +------------------------+------------------------+
     |                                                 |
     +------------------------+------------------------+
     | target_peer_id                                  |
     +------------------------+------------------------+
     |                                                 |
     +------------------------+------------------------+
     |                                                 |
     +------------------------+------------------------+

NOTE: This header structure is slightly different from the
previous one. I have taken in to consideration the suggestion
not to assume TCP/IP, as the WAN protocol. The origin and target
peer id are each 6 bytes long. This is to handle NON IP Peer
connections. I have also added the origin_wan_protocol and
target_wan_protocol fields to specify the type of wan protocols
used.

The protocol_version_id is set to 0x81
The message types could be one of the following:
          SSP_MEMBER_TO_BP      0xA0;
          SSP_BP_TO_MEMBER      0xA1;
          SSP_BP_TO_BP          0xA2;
          SSP_RELAY_RSP         0xA3;
The peer_ids give address used to reach the peers. If option 2
is chosen, the wan_protocol fields give the protocol used to
reach the peers.

Origin is the Peer that originated this frame and Target is the
Peer this frame is targeted to.

DIRECTORY SERVICES: A simple Pseudo directory service may be
implemented to further reduce the broadcasts. The border peers
can cache reachability information either configured by the user,
or learned dynamically. When group member requests a broadcast,
the border peer can send it to a select few peers instead of
broadcasting it to all peers.  The border peer needs to only
cache the group information for resources reachable in other
groups.

The following frames are handled by the border peers using
relay frames:
A. Broadcasts:
   1. CUR_ex
   2. Name Queries
   3. Datagram Broadcasts
B. Relay frames:
   1. ICR_ex
   2. Name Recognized.

Once the response is received, the origin router may choose to
setup a peer on demand before establishing the circuit. Since
there will be a small delay in setting up a new peer connection,
one of the options suggested was to pass XIDs as relay frames
while the POD peers are in the process of coming up. If this
option is chosen, care should be taken to handle sequencing
properly.

PEER GROUP RULES:
------------------
The following "rules" are proposed for implementation:
1. Only "extended DLSw" routers can be in a Peer Group.
2. A DLSw entity can belong to only one Peer group.
3. A DLSw entity must belong to a group to be a border peer for
   that group.
4. A DLSw entity can be border peer for only one group.
5. Only One group HOP permitted.

Rules for handling relay frames:
1. Frame from LAN is sent to all configured peers and/or to a
   border peer for broadcast relay.
2. Non relay frames received from a peer are forwarded only to
   the LAN.
3. Broadcast Relay from a group member is sent to other peers in
   the same group and/or to Border Peers of other groups.
4. Broadcast relay from a Border Peer of a different group is
   forwarded only to other group members in the same group.
5. Broadcast relay frames are sent only to one border peer in a
   group if multiple border peers are available for that group.

------------------------------------------------------------------------

---

From: [email-masked] (Tony Clark)
Date: 27 Jun 1995 17:36:49 GMT

This message was automatically generated upon receipt of your email message.  

Tony Clark is currently out of the office and will not return until Friday,
June 30th.

If your message is urgent, please contact Jim Vogt at (408) 7